The following section will describe the implementation process that took place in order to fulfil the design of the system described in the previous chapters.
		
This section outlines major problems we encountered during the implementation process and discusses our attempts to solve such problems. It also demonstrates what we have learned from the process.

The diagram in figure 5.12 is the class diagram for the GUI.

\begin{figure}[ht!]
        \centering

        \includegraphics[scale=0.50]{images/guiClassDiagram.1}
        \caption{GUI Class Diagram}
\end{figure}

Each window class represents a window of the user interface, and provides the functionality for these as expected. The \texttt{imageListCellRenderer} class is a custom renderer used by the main window to render images to the contact list. ButtonsGrid is the emoticons display window -- this is made up of a grid of buttons with images on them. AutoreplaceSmileys provides a method which takes a \texttt{String}, and converts the textual representation of emoticons, into the graphical one. User options is the class that displays the user options window. The login window, registration window and main window are all managed by the UIController class as shown in figure 5.2.


\subsection{Problems Encountered}

As we started implementing the user interface for JAM, the first major problem we came across was using appropriate layouts. We struggled with displaying components of the interface in the right places using basic layout such as Border Layout or Flow Layout. We then found out about the Grid Bag Layout which seemed to be the most suitable for what was needed in our design. However, when trying to adopt this layout to use in our design we still had problems displaying components the way we wanted. We spent quite a lot of time trying to fix the code so that it would display components as expected. However, we were not successful and we could not figure out what we were doing wrong, so eventually we decided not to use the Grid Bag Layout, regardless of how useful it could be for our design, and instead find a way of using only the basic layouts to fulfil our design. This resulted in the code to arrange the layout to be much more complex than required but in the end it worked and it allowed us to progress with our implementation.

When trying to solve our problems with using various layouts we referenced a number of Java Swing tutorial web sites as well a detailed book on Java Swing implementation. By doing so we were hoping to get a good understanding of how different layouts should work and we then applied that knowledge into implementing our user interface. However, when trying to implement the Grid Bag layout, even with the help of tutorial web sites we could not achieve the expected results. At this stage we decided not to use the Grid Bag layout and focus on only using the basic layouts instead. However, this time we did not start implementing straight away. Instead we prepared a small a plan of what layouts we were going to use and how. We split up our main design into smaller components according to the layouts that were required to be used for such components. This clarified and helped us understand the complex design we were about to implement. In the end, as our understanding of Java Swing improved, David managed to successfully adapt the Grid Bag layout into our code, reducing the number of layouts used and simplifying the overall design.

Another major problem we encountered was displaying any formatted text in the same format at the receivers site once the text has been sent to another user. Similarly, displaying emoticons after sending the message was an issue as well. Both the formatted text and emoticons were displayed properly in the message box while the sender was preparing the message. However, once the message had been sent the formatting of the text sent was lost and so any text was displayed in default settings. Similarly, emoticons were not recognised and displayed.

The problem of displaying both emoticons and the correct formatting of text to the receiver was solved by using HTML. The details of the text formatting were lost when the message was sent, so HTML was used to store details of the formatting and then pass them along with the message to the receiver. Displaying emoticons required the absolute path of the image file to be send along with the image so that the receiver would know where to access the image from.

The next issue we had faced was resizing the photographs that were to be used as avatars. Users were able to upload their own images to be used as avatars, and a part of the functionality of the system was to resize the given image so that it would fit into a field in a contact list. However, the images uploaded were not resized properly, instead a part of an image was cropped and used as an avatar. Simple resize methods provided by Java Swing did not resolve the issue.

The issue of not being able to resize the avatar image so it could fit on the page was resolved by another method that Java Swing provided called \texttt{getScaledInstance()}. This method can be used on an image and returns another image which is a scaled version of the one which called it. This way when a user uploads an avatar it can be properly scaled without any issues.
	 		 			
When trying to display user avatars within the contact list another problem that occurred is that an image can only be placed inside a JLabel and to display this the JLabel had to be placed inside a JList. However when a JList renders the elements inside it, it expects them to be strings as in order to render them it calls a toString() method. As there were images inside the JLabels the JList could not render them as expected and instead would display details concerning the error.

The problem with displaying avatars correctly was sorted by using a custom renderer. This solution was found only by looking through forums which contained solutions to this problem. From this we managed to find a custom renderer class online which would solve this problem. This piece of code is not our own and is marked accordingly so in our comments within the code. In order to implement this custom renderer instead of using JLabels directly each JLabel had to be placed inside a JPanel. Once this was done it could be added to the contact list in the same way as was previously tried. However this time the images and text were displayed as required and no errors were encountered.

Another problem occurred  once avatars had been added to the contact list. This is that getting the user details from within the contacts list and making each users contact list clickable was difficult. The reason for this is that in order to get the avatar image into the contact list it had to be placed inside a JLabel which then had to be placed inside a JPanel. This JPanel was then added as a component in the JList. This meant that the images and text where displayed as required. However it was impossible to get any information from them. This was a problem as originally the contact list was displaying input directly from the server, and this data was not stored on the client side.	 The other problem was that displaying the avatars this way had them all in one JPanel which was inside the JList. This lead to every contact within the contact list being selected once a user clicked on it, meaning that individual contacts could not be selected.

In order to make the contacts within the contact list clickable two things had to be done. Firstly each JLabel had to be put into a separate JPanel, so that each item could be selected individually. Secondly to each JPanel a mouse listener was added, this means that an event could be triggered when one of the JPanel’s within the JList was clicked on. This sorted the issue of clickability.

The issue of getting a contacts information once they had been clicked on was solved using an array. When the information about the contacts was given to the main Window class the details about each contact where stored in an array. As each item within the JList could be clicked on this would return an index which would correlate to an index within the array. This meant that the information about a contact could be retrieved from from the array and then used as required.

\subsection{Critical Reflection}

The process of implementing the user interface significantly improved our Java Swing skills. 			
		
We also learned where to look for information and how to use them to solve specific problems. On the other hand we also became able to work round problems and find alternative solutions to accomplish the same end result.
		
We also realised the importance of planning the implementation and how we are going to realise the design and the overall look of the finished product. It is important to know what the application should look like in the end, but it also helps to realise all the major intermediate steps and components involved into achieving this end result. Having a plan before commencing any implementation certainly helps to clarify the problem to a greater extent. However, this is something that we have not had due to our limited experience with Java Swing. We were not able to identify, at the beginning, all components required or steps that needed to go through in order to successfully implement the user interface. Instead, we learned most of Java Swing as we progressed with the implementation.
			
We learned how to approach the implementation of a more complex user interface in the future, due to gaining knowledge that we did not previously have as our Java Swing skills were rather basic.

\subsection{Known Issues}

There are many known issues with the functionality that would have been addressed if we had more time. They are:

\begin{itemize}
\item When a user receives a new message it is displayed at the top of the chat log instead of the bottom. This was not the desired functionality as new messages are supposed to be displayed at the bottom of the screen. This would be following the same way all other mass used instant messaging systems display messages.
\item If the user changes the windows colour they lose all the previous messages that were sent and received in the chat log. This is because changing colour uses a different kind of constructor and the ability to pass the chat log data from one constructor to another has not been implemented.
\item There is no validation on uploading images. This means that a user can upload any type of file they have on their computer as an avatar. The result is that an exception is thrown and the main window crashes.
\item There is a search bar for the contact list which would be used as a means for a user to search their contact list. A user can type into this and press enter, however there is no functionality behind the search bar. As a result nothing happens when the user presses enter.
\item There is an add user window which the user is capable of navigating too. However once the user clicks add on this window nothing happens, as there is no functionality behind it.
\item There is also a user options window. This gives the appearance of the ability for the user to change their nickname and status. However this has not been facilitated and does not work.
\item The functionality behind the registration window does not work. The only contacts within the system have been hand coded into the database and GUI.
\end{itemize}

In its present form, the client does not restrict the type of data which is uploaded using the avatar uploading functionality. This means that a user could upload maliciously crafted data, which would in turn be sent to other users requesting their avatar. This is not secure, and the type of data being sent to the server could be restricted, either through the user interface, or before being sent over the network, as part of the network component of the client.

In addition, there is currently no filtering of the user’s messages. This means that a user can send HTML, CSS or any other textual data. This data is then parsed on the recipient’s end, and can lead to unexpected behaviour. We performed some stress testing, which identified that Javascript could not be executed in this way. This is a side effect, rather than something that was explicitly accounted for in the implementation.

In general, more attention is required to ensure that input from the user is what is expected, rather than allowing unfiltered data to reach the server, and potentially, other clients.

In summary, the majority of the problems we encountered were tightly related to our limited experience with Java Swing. However, as we progressed with the implementation, trying to solve problems we came across, our knowledge and understanding of Java Swing improved significantly.
